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1.0 SUt lMARY 

This note describes the General Purpose Computer (6PC) ''subsyctem" 
of the Orbiter Data Processing System (DPS). Two interface areas are 
described. One is the area of 6PC intraconnections and intracommunications 
involving the ha rdwc re/software interface between the Central Processing 
Unit (CPU) and the Input/Output Processor (lOP). The other is the area of 
GPC interconnections and intercommin'ii cations and involves the hardware/ 
software interface between the five Orbiter GPC's. 

This note is one cf a series of Orbiter DPS interface descriptions that 
will be published on specific data buses and their respective Bus 
Terminal Units. (BTU's). The purpose of each design note is to thoroughly 
describe the hat dwa re/software configuration and interface to a level of 
detail sufficient for the integrated systems operation to be understood. 

Based on the detailed GPC interface description developed in Section 3.0, it 
is felt that the basic CPU to lOP interface and the GPC to GPC interface 
have the potential for trouble free operation. However, due to the 
complexity of the interface and the criticality of GPC synchronization to 
overall avionics performance, the GPC to GPC interface should be carefully 
evaluated when attempting to resolve test anomalies that may involve GPC 
timing and synchronization errors. 
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2.0 INTRODUCTIO N 

The Space Shuttle OPS design requires that the five Orbiter GPC's have the 
ability to conmunicete certain vital information. This information enables 
the GPC's to operate in a coordinated manner. The exchange of information 
between GPC's is accomplished by using five dedicated Intercomputer 
Communication (ICC) data buses and selected Discrete Input (DI) and 
Discrete Output (DO) linos. Each GPC is in coninand of one ICC data 
bus which is used by that GPC to send specially formatted serial digital ICC 
messages to the otiier GPC's. The selected DO lines are set or reset by 
each GPC to be input on the DI lines of the other GPC's. The set or 
reset condition of these discrete lines is used to communicate status or 
operating modes between the GPC's. The discrete lines provide GPC 
information exchange that is best communicated by on/off bit configurations 
and is available to be read continuously during program execution. 

A block diagram of the total Orbiter Avionics DPS (extracted from reference 
C) is shown in Figure 1. Only those DPS elements previously discussed 
are described by this design note. 
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BLOCK DIAGRAM OF AVIONICS OPS SYSTEM 
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j 3.0 DISCUSSION 

The reference material used during this effort Is listed In Section 5.0. 

3.1 GPC System Overview 

The hardware and software Interfaces within the Orbiter Avionics System 
are essential to the successful operation of the multiprocessor GPC 
configuration which Is designed for simplex and redundant computer operation. The 
DPS hardware and associated software must operate In a cooperative relationship 
which Includes hardware Bullt-In-Test Equipment (BITE) and software that 
check each other to prevent error or failure conditions from going undetected. 

The Interfaces between the five GPC's are referred to as Intercommunication 
and Interfaces between the CPU and lOP of a single GPC are referred to as Intra- 
conniunl cation. Figure 2 shows these hardware Interfaces. 

The Interconi.iunicatlon Interface utilizes both serial digital data buses 
(to transmit twenty-eight bit words containing sixteen data bits) and 
discrete signal lines (to convey certain discrete Information). Five ICC 
data buses are used to send und receive the serial digital data essential 
to the operation of GPC's as common or redundant set members. Each GPC 
has a dcd1cat3d ICC data bus to transmit messages to the other GPC's, while 
It receives messages from the other GPC's on the remaining ICC data buses. 

All GPC's exchange their ICCmiessages simultaneously at scheduled Intervals, 
a 1 MHz serial bit rate. . 

I ntraconmuni cation Involves the bi-directional exchange of Information 
between the CPU and the lOP that Is essential to operation of the GPC as 
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a unit. This is the first level of interface and must be operating in 
order for the individual 6PC to initiate and sustain the intercommunication 
processes. Intracoirmunication between the CPU and lOP utilizes a bi- 
directional thirty-four bit (includes two parity bits) parallel data 
channel and five interrupt lines. The data channel allows the CPU to 
communicate* through the use of program controlled Input/Output (I/O) 
commands, with the processors in the lOP to read, set and reset the discrete 
signal line registers associated \»ith the 6PC. The lOP processors 
communicate with the CPU by using the data channel as a Direct Memory Access 
(DMA) channel to access main CPU and lOP memory. This path is used to read 

instructions and read/write data froni/to memory. The lOP also communicates with 

the CPU via interrupts to indicate I/O completion or to indicate certain error 
conditions or change of status. The CPU reads the lOP interrupt status 

register with a program controlled input cotmiand to determine the cause of 

the interrupt. 

3.2 GPC I ntracommunication 

GPC Intracommunication involves the communication bctv.'een the CPU and the 
lOP and is conducted over a bi-directional thirty- four bit parallel data 
bus which is utilized as an I/O channel between the CPU and lOP. All 
infonnation transfers between the CPU and lOP are managed by the Channel 
Controller (CC). 

3.2.1 Direct I/O 

The CPU utilizes the I/O channel for direct I/O operations controlled by 
the CC. The CC consists of differential drivers and receivers for control 
signal transfer betv/een lOP and CPU. Specifically, an eighteen bit Df-IA 
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address register, a DMA address register odd parity generator, a thirty- 
two bit DMA input data register, an eighteen bit PCI/0 cormand register, 
a parity generator/checkcr, a thirty-two bit output data register, a DMA 
input data register, and other logic. The thirty-six bit bi-directional 
data consists of thirty- two bits of data, an jdo parity bit and a storage 
protect bit for each half v/ord. Under CPU control for direct I/O operations, 
the I/O channel operates at a worst case rate of eighty-four KHz (derived 
from reference G). 

The CPU conmunicatcs with the Master Sequence Controller (MSC) and Bus 
Control Elements (BCE's) by use of program controlled input (PCI) and 
program controlled output (pCO) instructions. The PCI/0 instructions are 
two thirty-two bit words. The first word is the ronr.iand, followed by a 
data word for the PCO instruction. For the PCI instruction, an lOP data word 
to the CPU follows. The PCI/0 instructions are used to control the CC, the 
Control Monitor (CM), the Redundancy Management (RM) logic, the Date flow 
(DF) logic, and the BCE/MSC local store (LS). The CPU controls the operation 
of MSC programs by loading the MSC program counter (PC) through use of the 
PCO LS instruction v/hich starts the MSC at a particular program; the BCE's 
register can be loaded by the CPU but the MSC must start them with an SIO instruc- 
tion. The MSC can control which program the BCE will execute by loading the BCE PC 
and/or base register using the MSC 'LBP' and 'LBB' instructions. The CPU can 
monitor the activity of the MSC arid BCE's by PCI instructions to read the lOP 
status registers that are set by the hardware and fisTuvare MSC/BCE logic. 

The MSC can monitor BCE activity by executing a 'repeat until' instruction 
which waits for the specified BCE(s) to enter the wait state by monitoring the 
associated bits in the Busy/Kait oi BCE-MSC indicator register status. The 
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BCE Indicates to the CPU and KSC that It Is finished with a program by 
executing the 'Walt' (WAT) Instruction which resets the Busy bit 
In lOP status Register 4. 

3.2.2 Direct Memory Access 

The lOP utilizes the CC for DMA capability to access CPU and lOP memory. 

The DMA capability Is under microcode control to acquire MSC and BCE 
program Instructions. The DMA may also read Multiplex Interface Adapter 
(MIA) output data from memory and write MIA Input data Into main memory. 

The requests for CP'J or lOP memory access by the MSC and BCE are queued 
In a FIrst-ln-FIrst-out (FIFO) DMA request stack that can accomodate up 
to sixty- four requests. The DMA goes Into a 'burst' n\ode 
of operation when eight or more memory access requests have been stored In 
the FIFO stack. The 'burst' node empties the stack, allowing no CPU I/O 
channel usage during this period. When the I/O channel Is operating 
under lOP DMA, the channel operates at 250 KHz In the normal mode, and 714 
KHz In the 'burst' mode. The Df4A rate will vary with other processor channel 
usage which may degradate access speed. 

3.2.3 Interrupts 

There are five Interrupt lines between the lOP and the CPU. The Interrupt 
lines are used to coninunicatc certain lOP hardware detected error conditions 
and program controlled interrupt requests. Each interrupt line is connected 
to the wire ORed output of a six bit interrupt register. Any bit set in the 
register will cause the interrupt, if the interrupt is enabled. The first 
two interrupt registers (A and B) have their most significant six bits 
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set by RM erro** detection hardware. The third Interrupt register 
has twelve prograirmable hits that can be set by the MSC 'OINT* Instruction, 
which Includes a mask of bits to be set or reset. The CPU Interrupt 
service routine can determine the cause of the Interrupt by examining the 
proper I OP Interrupt status registe by use of a PCI command, which will 
also reset the register bits. The CPU program reads the programmable 
Interrupt register C with a PCI command and interprets the twelve bits as 
an Effective Interrupt List (EIL), as Indicated In reference H. Each bit 
corresponds to a unique lOP interrupt program number, which usually 
Indicates that a MSC program Is finished executing. The last two Interrupt 
registers (D and E) are spares. The Interrupts and I/O channel between the 
CPU and lOP Is graphically depicted in Figure 3. 

3.3 GPC Intercomputer Discrete Lines 

There are forty discrete input and thirty-two discrete output signal lines. 
Eighteen of these lines are Interconnected between the five GPCs and are 
used to communicate synchronization codes (twelve lines) and RM fall- re 
vote status (six lines) to the GPCs (see Figures 4 and 5 respectively). The 
discrete signal lines are terminated In thirty- two bit registers In each 
lOP. The lOP Control Monitor controls the loading of the DO register and 
reading of the two DI registers through CPU issued PCl/PCO direct I/O 
coninands. The discrete input lines are split between two registers, A and B. 
The first thirty-two bits arc in DI register A and the last eight bits arc 
In DI register B. The remaining bits in register i) arc not used. DI bit 
positions P - 7 and 12-13 are hardwired to the Crew Control Panel (CCP) to 
indicate Halt, Standby, Run and IPL switch positions. Hardwired bits also 
Indicate Mass Memory Unit (MMU) status. Backup Flight Control System (BFCS) 
engage, and TERMINATE/NORMAL switch positions. 
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The synchronization discrete signal lines (see Figure 4) are arranged so 
that GPC 'N' sync bit DO lines 1, 2 and 3 are connected to the DI lines 
of GPC *N+1', 'N+2', and 'N»3*. The DI sync lines are grouped by sync 
bit instead of by 6PC. The RM discrete signal lines (see Figure 5) 
are arranged so that GPC 'N' failure vote *fUl', 'N+2' and 'N+3' DO signal 
lines are connected to the failure vote DI lines of CPC 'N+l'» 'N+2' and 
'N+3', as indicated in Reference J. The RM failure vote discretes are used 
every minor cycle. The synchronization discretes are used at the slowest 
rate every minor cycle and the fastest rate is directly related to the use 
of I/O and Supervisory Calls (SVC's) by the application programs, 

3 • 4 Gf C Intercomp uter C ommunication Overvie.v 

GPC intercommunication is required to operate a multi coinputer, mul +iprogramming 
configurot ■ ,r. in a coordinated, cooperative manner. The GPC's operate in a 
coordinated manner by exchanging similar information and by cross checking 
each other. The CPC's that are executing the same programs are operating in 
a redundant configuration an'< should bo executing the same instructions at 
tlie same time. The GPC's that are operating as memtn_rs of a redundant 
conf igu> ation mi.jt exchange information that allov/s them to synchronize their 
nroqraii execution. This exchange of information is accomplished by use of 
dedicated intercomputer comfiiunicalion data channels and discrete signal 
lines. The cross checking among GPC's hy ICC data exchange also allows the 
GPC's lo detect an errant GPC and remove it from the redundant set in order 
to keep the Data Processing System operating correctly. 

3.4.1 IC C Data Buses 

The main inlori or.nection between the GPC's is the five ICC Data buses. The 
ICC data buses consist of U.'isted, sliioldod pairs. 


Each GPC commands a 
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dedicated ICC data bus that Is Interfaced to the other four GPC';«. The ICC 
data Is transmitted in serial Manchester II code at a rate of one million 
bits/second. Each ICC data bus Interconnects an lOP MIA of each of the 
five GPC's. GPC's transmit serial data over the data bus and can process 
simultaneous data transmissions on the ICC data bus set. The GPC's communicate 
over the ICC data buses by transmitting twenty-eight Pit command words » 
command data words, or response data v/ords. Each lOP has five BCE's that 
are dedicated to the five ICC data buses. Each GPC Is commander of oni of 
the five buses and Is a listener on the other four buses. The comnunder 
proceeds each message transmission with a "Listen Command" which Is a command 
word with an Interface unit address (lUA) of 01000 binary. The transmitting 
BCE sends its ICC message when the receiving BCE goes Into the 'receive' mode 
of operation. 

The transmission process begins by cither the CPU or MSC selecting the BCE 
associated with the ICC channel. The BCE sends a 'listen' command with a 
conrion address that will start the other BCE's on the bus the-t are executing a 
Wiat-for-Index (WIX) instruction. The Index is used to calculate the address 
of the Instruction that will process the data sent by the coiiinand BCE. 

3.4.2 ICC Traffic Categories and User Functions 

There are two distinct categories of GPC interconinunication- serial digital 
and discrete. These modes of CPC intercominun'cation can he used separately 
or in conjunction with each other. The serial digital intercommunication is 
effected by use of ICC data bus messages v/hich are converted from parallel 
twenty four bits words (sixteen data bits plus overhead), transmitted using a 
serial modulation scheme, and re-converted to a parallel twen+y-four bit data 
word at tlie receiver. 
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The serial digital ICC traffic is used to convey messages containing one- 
or more words of data between the GPC's. The forty DI and thirty- two 
DO signals lines are used to indicate the status of switch positions or 
other set/reset, enablc/disable, on/off two-state conditions that can 
best be intercommunicated using single bits or groups of bits. The ICC 
traffic is used for conmunication between GPC's that arc members of a coninon 
set (CS) or a redundant set (RS) of GPC's. The CS traffic is intended for 
exchange between active GPC's that are in either the Standby or Run mode and 
includes messages that relate to GPC processing that is not controlling 
flight critical buses and related functions. The RS traffic is intended 
for exchange between GPC's that are cooperating and coordinating the 
control of the flight critical data buses and other related control functions. 

The CS includes the RS, but the RS does not necessarily include the CS. 

Figure 6 shows the ICC user functions. One of the major users of ICC 
communication traffic is GPC Redundancy Management, which is composed of 
GPC synchronization processing for both the CS and RS and Fault Detection 
Identification (FDI) processing. There are four basic synchronization 
procedures, which include System Software Interface Processing (SSIP) 
synchronization (CS) , and Timor, I/O and SVC synchronization (RS). Synchronizatioi 
is required only if two or more GPCs arc active, and establishes a common 
startirig point in the same program being executed by different GPC .. FDI 
processing, part of I/O coinplet-on processing, votes the RM sum words generated 
by each member of the RS. The System Interface Processor uses the ICC channel 
to exchange information relative to CS member GPC's. DPS configuration 
management uses llie ICC channel to communicate clvrjes necessary to add or 
delete members of the common and redundant set. Bus configuration changes 
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are coninunicatcd on the ICC channel among RS members whenever there must 
be a change of GPC i>r1niary or secondary bus conMnand. 

3.4.3 JCC j£af f 1 p_ I n i t 1 a lji« ti^on 

Ihe ICC traffic initiation for the Rb and tS are derived from the same 
progranviiable counter but, due to the queuing stack for the clock interrupts, 
occur at different times. The CS ICC traffic, for one or more GPC's, 
occurs at every SSIP synchronization point and is scheduled by the GPC 
Locator program to occur every forty milliseconds by placing a Timer Queue 
Element (TQE) in tlie timer queue stack. The RS traffic is initiated at 
every Programmable Timer 2 (PC2) interrupt, whereas the CS traffic is 
Initiated only if the top active TQE is a SSIP synchronization request. 

The ICC I/O traffic is initiated by a call to the Flight Computer Operating 
System (FCOS) SVC service routine which dispatches the I/O request to the 
HSC control program to initiate needed BCE programs. BCE programs a»"e 
designed for a specific interface unit address. The BCE program executes 
in either the commmand or listen mode and the conmand BCE sends a 'listen' 
conmand to 'listening' BCE's. BCE programs expect a fixed number of ICC 
message words to be transmitted. The Index from the 'listen' command 
determines the BCE Program to execute vdiich in turn determines the number 
of words to receive. 


3.4.3 ICC Message H and ling 

ICC messages arc handled by throe software functional groups-message 
collection, message routing, and message dispatching, 
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The collector and router are part of the User Interface (Ul) software. 

The ICC message collector provides support and buffering of Individual ICC 
messages from System Control (SC) programs, such as GPC Reconfiguration. 

The Individual messages arc collected Into a single message block comprised of 

coded modules. The ICC messuge buffer is a 128 x 16 bit buffer In the 

common pool part of GPC memory. There are f’ve copies of the buffer In 

each GPC; one for each GPC In the common set. The ICC message buffer for 

GPC 'N' Is used to store messages Input from other GPC's, whereas, ICC 

message buffers 'N+1', *N+2', 'N+3', and 'NM' (modulo 5) are used to store messages 

to be output to those GPC's. The first seven data slots in each buffer 

are fixed while the remainder are used for variable length messages. 

After the message is transfered to the ICC buffer. Indices are updated 
so that the process will accept additional messages, If there is room. 

Once the ICC messages have been exchanged between tl»e common set GPC's, the 
ICC message router is invoked to distribute the received message, from the 
four input buffers, to the specified processes for which they are destined. 

The ICC Message Table (IMT) contains control data the router uses for 
processing the packed messages. The input ICC buffers are scanned and a 
comparison made on message destination and typo codes. Depending on the 
IMT entry, the message may be processed iiTtnediately , scheduled for later 
processing, withheld from moving, or moved to a buffer invoking no processing. 

To avoid redundant processing, reduttdant messages can be filtered out. 

During interface processing, the ICC collector is called to finish processing 
any message. Next, ICC messages arc built for each common pool (COMPOOl ) 

ICC flag that is set and the ItC message collector is called to place the 
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the ICC messages In the ICC message buffer. The flags are reset if the 
ICC message collector accepts (has room In ICC buffer) the message. 

After all messages are built, a SVC Is Issued to Invoke ICC output and 
input traffic. The I/O SVC Handler (FIOSVC) attempts to start I/O operations 
by passing an I/O Queue Element (lOQE) to the lOP Dispatcher (FIODISP) 
which in turn Initiates the request by passing a mask of buses needed in 
the request to the HSC Control Program (FlOf'CflTL). FIOMCHTL starts the 
proper BCE's to executing BCE programs based on the input I/O monitor mask. 

The BCE programs are designed for a specific interface unit address and 
execute in eitner coiiimand or listen mode. The command BCE sends a 'listen' 
command to listening BCE's. The 'listen' indices are used to detennine 
transfer word count for ICC requests. When the ICC traffic exciiatKje is completed, 
the ICC message router is called to distribute the received ICC messages. 

3 . 5 GPC ICC S ynchroiii;;>iti an Fea tures 

Synchronization provides system wide, time coordinated sampling of BTU's, 
use of the same data sets for RS GPC processing, coordinated commands to 
Initiate sultsystcm actions, and coordinated GPC information exchanges and 
associated processing. The synchronization process involves the intercomputer 
exchange of three-bit binary sync codes over the discrete signal lines. CPC 
'H' ou' uts its discrete code by loading the DO register bits 20,?/* and 28. 

The sync codes from the other CPC's arc input on the DI signal lines. 

The sync bit from GPC's N+i , N+2, and N+3 (modulo 4) are input on Dl linos 
20-22, 1 iKewise sync bit 2 on DI lines 24-26 and sync bit 3 on DI lines 28-30. 

The synchronization processes iiave a priority order. Timer sync and 
SSIP have highest priority, I/O sync is next, and SVC sync has lowest 
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priority. This priority structure allows the I/O sync process to Interrupt the 
SVC sync process, and SSIP or timer sync to Interrupt either I/O or SVC sync 
processing. The priority structure is used to prevent sync failure due to 
different GPC's being at different sync points at the same time. This could 
occur duo to a processing time skew which v/ould allow one 6PC to arrive at a 
higher priority sync slightly ahead of the other RS GPC's. Lower level sync 
processes must enable higher priority sync process interrupts when there is 
a sync code discrepancy. 

The detailed synchronization functions are discussed in the following sub- 
sections. All functional flow charts (Figures 7-15) are extracted from Reference 
D and are Included in this design note for completeness. 

3.5.1 Initial SS IP Sy nchroniz a tion 

Initial SSIP synchronization is part of the GPC initialization SSIP processing 
and is used to determine active GPC's and add them to the conrion set (see 
Figure 7). The process involves letting the coireTion set sync codes, read 
from the sync discrete lines, dissipate. Ihe sync discretes are then read for 
a period of fifty milliseconds or until a GPC sends a common sync code. If 
no conr.ion sync code is detected, the discrete sync code lines are reed for 
ten additional milliseconds to allow other common . 't members to report. Any 
additional convnon set members detennined are added to the cohuiion set sync mask. 

3.5.2 Normal SSI P Synchroniza t ion 

Normal SSIP synclironization (see Figure 8) is scheduled to execute at every 

minor cycle. SSIP sync processing gains CPU control when its TQC time 

expiies. The PC2 interrupt service routine counts out tP.e scheduled time 

interval. The sync codes of non-coimon set member, are read and these 

GPC's are allov/ed to join the CS from the IIAIT state. The sync code discrete lines 
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of all CS members are read and checked for the connon sync code (100). or 
until a Time Counter (TC). set to a COMPOOL value, times out the sync 
check process. Any CS member falling to Issue the common sync code In 
the allotcd time. Is removed from both the common and redundant sets by 
the Sync Fall Processor. Since the TC Is rc-lnitiallzed each time a 
previously missing CS number Issues the conmon sync code, worst case time 
for CS sync would be (TC value)x( number of CS njcnibcrs). When a CS member 
has failed a CS sync. It Is Ignored at all further CS and PS sync points. 

Data bus rc-configuratlon may be necessary when a RS mcn6er controlling 
certain data buses Is removed from the RS. Rescttir.g the TC value di' Ing 
synchi'onizatlon assures that all CS members leave the sync point together. 

If a nc-w GPC is added to the CS or if the minor cycle counter was 
decremented to zero on the previous cycle, then the Master Timing Unit (MTU) 
is read usinvj a pre-initialized lOQH issued via an SVC, the Time 
Management Processor (TMP) flag is set for SSIP, and the minor cycle counter is 
reset to maximum value. Before exiting the normal SSIP process, the minor cycl 
counter is decremented and the null sync code (111) is issued on the sync 
DO lines. 

3.5.3 Timer Synchronization 

Timer synchronization (see Figure 9) occurs at every PC2 interrupt except 
v/hen the interrupt expires the SSIP TQE. The time sync code (101) is issued 
from the TQE expiration routine. The Dl ,ync lines of the RS members are 
read and checked for the timer sync code or until a time counter, which has 
been set to a COMPOOL value, is decremented to zero by the loop execution 
time. Any RS member that does not issue a timer sync code within the 
allotted time is deleted from the RS by the sync fail processor (FCMSFAIL). 



Timer SyrcSronization 
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When all RS mcmhers have Issued the timer sync code on their DO lines » the 
01 register Is read and the sync lines checked again for stability. If a 
timer sync code is detected from a 6PC previously issuing a Invalid sync 
code, then the time counter for the sync read loop Is reset, thus allowing 
the GPC's to leave the sync point together. A short delay is processed to 
allow sync code detection by other GPC's. The sync fail processor will 
Initiate updating of bus/data path masks and CALL the Bus Reconfiguration 
routine for buses conwnanded by a fall-to-sync GPC. A flag Is set in the ICC 
Flag COMPOOL area to Indivate that the RS mash has been updated and a message 
should be generated on the next ICC message exchange cycle to communicate 
the RS mask change to the other GPC's. The null sync code (111) is issued 
on the DO sync lines before the time sync routine returns through the PC2 
Interrupt handler. 

3.5.4 Input/Output S ynchronlration 

1/0 Synchronization Processing is used to synchronize 1/0 completion (IOC) 
Interrupts between the GPC's (sec figure 10). The interrupt is initiated by 
execution of the MSC '01 NT' Instruction. The prograi:i:nable interrupt 
Instruction Is executed by the HSC when it has detected that an I/O task 
has been completed by a monitored BCE. The 1/0 sytu .ronization process 
involves synchronization betv/cen either the CS or RS depending on the sync 
type bit set in a half word of the lOQE, whidt provides the control iiiforii'ation 
for a single 1/0 request. The 1/0 completion processor gains control of 
the CPU by a Program Status Word (PSW) swap, v;hich in turn calls the I/O 
synchroni zation process. 



I/O Synchrcnizotion 
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An lOQE flay bit Indicates if the completed transaction had errors. The IOC 
sync code (010) is issued if no I/O errors occurred or the Input Problem 
Report (IPR) sync code i< issued on the 00 sync lines (I/O errors are 
indicated). The process goes into a loop rcacing the DI register and 
checking for IOC or IPR sync codes sent from the members of the syncing set 
(CR or RS). A time counter dftcremented by the loop execution time, is set to 
an FCOS COMPOOl value to time the syncing process. If the correct sync: 
codes a'^e not read in the alloted time, tiie sync fail processor (FCMSFAIL) is 
called *0 remove the fail-to-sync CPC from the syncing set and perform any 
necessary bus reconfiguration. The DI register is read again to check the 
sync codes for stability. If the two reads are not identical or the 
sync codes are not IOC or IPR then the timer interrupt is enabled, then 
disabled, to allow a possible RS time synchronization process to gain CPU 
control. If no interrupt occurs, then the last sync codes input are cliecked 
for a correct sync code from a GPC previously issuing an incorrect sync code. 

A new correct sync code will reset the time counter and start the sync code 
input loop from the beginning. If after two identical inputs, the sync codes 
are IOC or IPR, then a delay is processed to give the other fd’C's time to 
leceive the cori ect sync code. Tlie sync codes art again input for a third 
tirce and if the sync codes are IOC or IPR, thett tlie process exits the input 
loop. Mext, the null sync rode (111) is issued by loading the DO register. 

IPR codes received irom any of the GPC's arc saved for loter protected 
transaction processing. If the lOOF device 10 indicates IC(, tor IPK, then ati 
ItC/Ji’k lOQE is (|ueued. The I/O sync in pitigress flag is reset to zero before 
control is returned to tfio I/O completion processor. 
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3 . 5 . S S VC Synctuonlzati un 

The Supervisor Call synchronization process is the lowest priority 
synchronization process and is invoked at SVC interrupts which request 
data gathering o. queue nianipulation functions (see Figure 11 a). Tht interrupt 
causes a PSW swap that puts the CPU in the supervisory state from which 
program controlled I/O (PCI/0) can be performed. 

The SVC synchronization process begins by setting the SVC sync-in-p*'ogrcss 
flag so that if higher order synchronization processes (I/O and timer) interrupt, 
the SVC may be re-issued. The 01 register is read and the sync code lines 
of all RS members checked for the SVC sync cede (110). If the SVC sync code 
is not received, a time counter, set to a UI COfiPOOL value, will terminate 
the synchronization process. If the SVC synchronization process times out, 
the fail-lo-sync CPC's are removed from the RS. The DI register is input 
twice to chock for stability. If the two inputs arc identical and all the 
sync codes are SVC, then a shcrc delay is processed and the 1)1 register is 
input and checked a third Ji'me. If sync codes are correct, after the third 
•read, the null sync code (111) is loaded into the UO register, the 
SVC sync-in-progress indicator is reset, and the program exits. If the 
two input reads were not identical or if all the sync codes v.'crc not SVC, 
tfien the timer and I/O intetrupls arc enabled and then disal)lcd. If no 
inlnrupl occirs, then tlie last DI register input is cliccked f»r new correct 
sync codes reported from previously incorrect GPC's. If a nev/ correct sync 
is delected, then the input tine;* ccjoter is reset, to mar.iivui:! value and 
the I'l register itipul loop is started from the bogitining, thereby enabling 
the GPC'i. tO exit tlie input loop together. The synchronization cedes are 
sumnarized in I i (jure lib. 


j CD3 
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SV'C Synchronization 













1.3-DN-r.01;04-037 
Pdcje 31 


3.6 Fault Detection Identification 

Another form of RM is Fault Detection Identification (FDI) pt'oeessing 
(sec Figure 12). fPI votes on the Hfl checksum v/ords, which are calculated 
by the Guidance, Navigation and Control (GN^iC/ hast executive module, 
for specified critical output commands. These sum words are transmitted on 
the ICC data buses between RS members so that every fif’C receives one less' 
sum v;ord than the number of GPC's in the RS. Each FS &PC compares its sim; v;ord 
with the other CPC sum words and sets a NOGO vote, against itself or the other 
GPC's, v/henever there is a sum word difference. GPC counters are transferred to 
other GPC's by ICC message once per second. Nominally, three conseciitive NOGO 
opinions of a CPC are voted before the associated GPC DO register fail vote 
bit is set via the appropriate bit set in the Set Fail Discretes Mask of the 
Communications Vector Table (CVT). The RM sum word is the first thirty-lwo 
bit v/ord in each ICC Buffer. 

Sys tem Inter fa ce Proc essor 

Anothei major user of ICC is the System Interface Processor (SIP) which 
provides control for system- wide processes which arc required to operate 
simultaneously in a coordinated manner in the CS meml)cr GPC's (see figure 13). 
The SIP is scheduled by the GPC Location process to execute every minor 
cycle when critical applications processes are not active, unless the GPC 
is in the MALT mode or turned off. The CS mask is used to deteini'no if 
other Gl’C's are active, and if so, a wail for ICC I/O is processed. The 
RM sum word is iiuvcci to the ICC buffer, then the ICC Message collectoi 
is forced to tenninate processing of any message inlerru!»ted by SII*. An 
ICC nu’ssage is built for each active GPC fot every UX flag bit that is set, 
indicating an updated value or status. The bits luc set by applications and 
control processes 'jotweeii inimn' cycle [:oints. Onro the u’.cssagos are 
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built, an FCOS SVC Is Issued to initiate the ICC message t*‘ansmission. 

The data transferred can be self status for other GPC's, internal clock 
time (when time management function is invoked after sync routine), 
keyboard input configuration change, systems status data for display, 
system software logic control parameter status, annunciation conmion for 
all memory configurations, and mass memory I/O contention coordination data. 

The ICC router processes the GPC's own ICC buffer and any ICC buffers 
received from otiier active GPC's when ICC message transfer terminates. The 
ICC buffer controls are reinitialized for the next minor cycle. 

DPS Reconfiguration 

DPS reconfiguration also utilizes ICC and is conposed of GPC ReconfigurrMon 
and Data Bus Reconfiguration. Reconfiguration is initiated by user inputs 
which specify the state to which the DPS and its elci»c‘nts must be nodifivJ. 

The prime GPC controls the reconfiguration of GPC's wliile any other GPC involved 
in the process operates under the direction of the prime GPC. GPC 
reconfiguration is riecessary when a major functiof! Operational Sequence 
(OPS) transition requires a change in the GPC RS to support the OPS. 

3.8.1 GPC Recon fi gu rat i on 

The CPC reconfiguration processor services requests to overlay main i.icmory with 
new iiiemcry configurations and controls the forming of nw sets of rcdund.mt 
GPC's (see figure 14). GPC's in the CS win’ch arc needed in tlio new RS for the 
new OPS receive an ICC i.iossage from the prime GPC con.nur.i eating the imporuliug 
clianges in the DPS configuration. Messages transfeted via ICC lo initiife and 
control rctonf ignrat ion in secondary GPC's arc of five types. The first typo 
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tells new CPC's for the RS being formed that reconfiguration Is about to 
take place. The second type message tells the new CPC's for the RS being 
forTtJcd that a new OPS Is to be initiated. The third type message tells 
new CPC's for the RS being toniied that the overlay lor the new OPS Is to 
proceed now. The fourth type message is the reconfiguration MMU overlay 
completion status, and the fifth type message sends application process 
initialization data to new CPC’s in the RS. ICC messages are also built 
to control RS Initiation and CPC sync for memory overlay Initiation. The 
new RS of CPC's is synchronized after which the MMU read is requested of 
all CPC's. The prime CPC commands the K’-1U load and transmits MI-IU '.listen' 
Instructions via ICC channel message to tie secondary CPC's. After the MMU 
load, system initialization ICC messages jre transmitted to the 
secondary CPC's, ’'’he messages are lists of processes that must continue 
operation across the OPS transition and are resident in the major function 
(MF) overlay. 

3.8.2 D ata Bus Rec onfiguratio n 

The data bus configuration change process provide a means for changing 
coniiiand of a data bus from one CPC to another (sec f igure 16). One CPC 
releases command of a bus, while another CPC assumes command of that bus. 

The bus configuration change proccfss causes the appropriate BCC to be set 
to 'listen' or 'comniand' . A bus reconfiguiMtion messago is passed to the 
ICC Message Collector and issued at CS syruln oni zation time to all other 
active CPC's. Upon comploLlon of the ICC, tia- ICC M-essage RouLei distril>ut(s 
the bus roconf iguration message to the Bus Conf igural ion Chanjo Processor. 
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The ICC buffer number and array index point to the message to be processed. 

The DI register A data in the ICC bufft*r is used to detennine the GPC RUN/ 

STBY status. 

The bus configuration messages can originate from major function switch change, 
computer/CRT key input, DPS Configuration Monitor Display (formally executed 
by the computer/bus key input), Launch Data bus (l DR) coinmanacr or bus change, 
new OPS request, OPS terminate request. Force OPS 0 request, or fail-to-sync 
request. Bus configuration table';, the DPS Status table, the GPC Status table, 
and bus/data path masks and counters are updated and this information is 
transferal to all Gf'C's via ICC message so they can update tiicir corresponding 
tables at the conclusion of the processing. 


1.3-DN-C0t>04-037 
Paye 39 


4.0 C ONCIUSION 

The Orbiter [)ata Processing System Intercomputer and intracomputer processes 
have been described in sufficient detail to be under'tood without reference 
to other Shuttle dorunients. Based upon tliis description, it is noteworthy 
to emphasize that intercomputer communication processing is clearly one of 
the most complex areas of this multicomputer, multiprogranrning system and 
serves the most critical function of redundant set CPC operation. Synchronizati 
and the associated ICC message traffic require extremely conurlicatod and time 
critical logic, v/hich is by its nature subject to potential eri'ors. The 
basic design has the potential of correct operation but should be considered 
suspect if any timing problems occur during testing. 

The timing of ICC message traffic is critical to the operation of the redundant 
set. Variations in response to interrupts, the processing time betv/cen 
the interrupt and the resulting I/O operation, may provide sufficient time 
si . ..eu.'oen RS CPC's to cause a transmitting BCE to send a message before 
the receiving BCE is initialized to receive it. More analysis and some 
laboratory nicasureinents will be needed to verify that no timing problems 
exist. 

Frequent synchronization of the redundant set (BOO to 600 synchronizations 
per second) may cause a CPU execution time overload. The possibility of 
combining appl ications "cal Is^for I/O to reduce the nuMibcr of redundant set 
synchron izations should be considered as a moans of reducing the CPU overhead 
associated with I/O and synchronization. 
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